A typical data transport network operates in a connectionless mode whereby there is no negotiation between the transmitter/receiver and the network with regard to the type or quantity of traffic that is to be sent. The transmitter simply sends the traffic on the network, and relies on the network components to accurately deliver that traffic to the receiver. These network components consist typically of outing nodes (also known as routers or switches) joined by physical links. The main function of the routing nodes is to direct incoming packets to the appropriate outgoing links.
Many communication network applications have adopted the Internet Protocol (IP); a library of routines called by various network communications applications for transporting packets of data from node to node. The Transmission Control Protocol (TCP) is used for most IP network transactions and provides for both reliable transmission and rate adaptation in order to adjust to available network bandwidth. TCP allows use of available bandwidth and accommodation of different rates at different points in the internetwork or network.
Within the IP networks community there is a growing interest in managing data traffic in the form of aggregate data flows.
The term “aggregate data flow” is used to refer to a plurality of data flows (which are streams of data packets having a consistent or variable transmission rate) which are treated as a group in order to allow common treatment of the flows over a defined network path. The data flows may be from diverse sources. Such grouping may be achieved by interleaving the packets making up the flows (in no particular order, but generally in the order of the time at which they arrive at the aggregation point) into a single flow.
In Internet terminology, aggregating data traffic by encapsulating it into a single Internet protocol (IP) packet flow is often called tunnelling. The encapsulated traffic flow through the IP network is referred to as an aggregate trunk or tunnel. Another form of aggregation is Multi-protocol Label Switching (MPLS), which minimises overhead by using a very small label to encapsulate IP packets instead of a full TCP/IP header.
Aggregating data flows into one flow simplifies management of the network; routes can be identified for the aggregate flows more simply than if all individual data flows were visible. Treatments such as bandwidth allocation or forwarding priority can be assigned to the aggregate flow rather than having to manage the treatments on an individual flow basis. Performance commitments, for example, from a carrier or ISP to its customer are likely to be made at the aggregate flow level rather than for individual flow levels. Often the bandwidth that these aggregate flows may use is fixed. Alternatively, the bandwidth that a particular aggregate flow may use can be determined by host-based mechanisms that implement elastic bandwidth sharing with other aggregate flows.
Currently, TCP is the most widely used mechanism to achieve elastic bandwidth sharing between end-to-end IP flows and most core networks rely on end-system TCP to provide congestion control. However, since end-to-end TCP will strive for fair sharing between individual flows, this will not result in the type of bandwidth sharing and congestion control required at the aggregate flow level. TCP-like mechanisms for congestion control of aggregates have recently been proposed. For example, a paper entitled “Traffic Management for Aggregate IP Streams”, by Alan Chapman and H. T. Kung, and published in the proceedings of the Canadian Conference on Broadband Research, November 1999, pages 1-9; describes such mechanisms. Typically, as network resources, such as the nodes and physical links connecting them, become congested, senders receive congestion notifications. Each sender controls transmission of a particular aggregate data flow. In standard TCP, congestion is notified by discarding data packets. For aggregate streams a separate control protocol is used for indicating congestion and no data packets need be discarded along the aggregate's path. Congestion indications from a node on the path can be triggered by buffer fill or link usage.
If the aggregate flow reduces its total rate of transmission, it is necessary for the originating data sources to likewise reduce their sending rates or have packets discarded at the input to the aggregate flow. Some end-user protocols (e.g. TCP) have mechanisms to adjust their data transmission rate in response to congestion notifications and to accommodate for lost data packets, while other protocols (e.g. UDP) lack such mechanisms. If a source does not reduce its sending rate it will cause excessive loss of packets at the aggregation point even for flows that are trying to adapt to a congestion condition.
A distinction between streaming and non-streaming data is made herein. Streaming data is an uninterrupted stream of data packets at a consistent transmission rate for a relatively long period of time, whereas non-streaming data (such as transactional data) has a transmission rate that can be bursty, or variable, in nature. A video or voice application would typically produce streaming data, making use of the user datagram protocol (UDP) for example, whereas a file transfer would typically produce non-streaming data, making use of TCP, for example. Both streaming and non-streaming data are referred to herein as data flows in the general sense. That is, a data flow may be either streaming data or non-streaming data.
Many data applications can be negatively impacted by high packet losses. If streaming data applications do not adapt to network congestion, they can cause high packet losses that would be spread over all data flows. It would be preferred that the loss of packets be allocated to one or more selected flows, rather than spread over all flows. Better still, it would be ideal if packets from a new streaming flow were never forwarded or a transaction was not started if they were expected to cause unacceptable losses for existing flows in the network.
To protect existing streams from problems caused by lost packets and interrupted data rates; it would be desirable to ascertain whether there is sufficient bandwidth available on an aggregate data flow's path for a new stream or transaction before admitting that new stream or transaction into the aggregate data flow. Similarly, if the bandwidth available reduces to less than that needed for all streams or transactions, it is desirable to discard selectively from chosen streams or transactions.
Some current methods of setting up paths through a network involve multiple interactions between the network nodes and edge points of the network or a central resource management entity. For example, the Resource Reservation Protocol (RSVP) defined by the Internet Engineering Task Force will query all nodes on a path as to the availability of bandwidth and reserve a particular amount of bandwidth for a period of time. Such protocols require mechanisms associated with each node to make admission decisions arid to signal the results of bandwidth requests to each node. Such an arrangement is necessary to reserve a guaranteed amount of bandwidth for a path through the network. However, the reservation is not amenable to fast change. Hence, these current solutions are more suitable for guaranteeing a fixed amount of bandwidth for a path through the network.
In order to achieve more efficient use of the network and to provide more resources to data sources, dynamic adjustment to the amount of bandwidth reserved for a path is desirable. In this case, the data source of a point to point path could take advantage of variability in other data traffic by using bandwidth that is made available from inactivity on other paths. The bandwidth reserved for the paths would no longer be fixed but could increase over and above any guaranteed minimum bandwidth (GMB) without detrimental effect on other paths.
These issues also apply to data flows in the form of transaction oriented traffic.
The term “transaction oriented traffic” is used herein to refer to a subset of the data flows discussed above and are communications between at least two parties which are associated with either a request being sent from one party to the other or a response being sent in reply to the request. Typically the whole of the request and response have to be reliably transmitted and received for the communication to succeed. Transaction oriented traffic includes but is not limited to world wide web accesses and remote procedure call invocations such as interactive database accesses. As such, transaction oriented traffic forms a major component, perhaps as much as 70% of today's data traffic.
Because transaction oriented traffic and hence transaction oriented services are widely used there is increasing demand to avoid overload in communications networks from transaction oriented traffic such as traffic from web-browsing. Guaranteed quality of service for such traffic is advantageous. However, currently, network congestion control schemes often simply discard packets, delay packets to the extent that the retransmission timeout of the protocol is triggered or close transactions that have been started but not finished. This is particularly wasteful of network resources because “work” is effectively done without producing any results. That is, packets associated with transactions that are started but not finished use network resources but do not produce an outcome that is useful for end users. Thus in order to provide quality of service for transaction oriented services and traffic, it is important that few packets are lost and that once a transaction has started, it should not be subject to closure or poor performance.
Transaction oriented traffic has many characteristics that differ from non-transaction oriented traffic such as file transfers or voice communications. For example, an item of transaction oriented traffic such as a world wide web access has a relatively short duration or persistence time as compared with a file transfer or voice communication. As well as this, the size of items of transaction oriented traffic is typically relatively small compared with file transfers and the like. Transaction oriented traffic is also inherently bursty and as such is difficult to control or predict.
Existing network congestion control schemes are often complex and require new signalling schemes to be implemented at many nodes throughout the communications network. This adds to costs because many nodes need to be adapted. As well as this, many existing network congestion control schemes such as reservation signalling schemes are simply not suited to transaction oriented traffic. For example, the overhead of reserving resources to guarantee the delivery of transaction oriented data is typically out of proportion to the size of the data delivered and the limited persistence of the connection. Each transaction or small set of transactions is likely to need a separate reservation especially in the web access service case and this increases the number of reservations required.
The characteristics of transaction oriented traffic discussed above have meant that this type of traffic often is not treated optimally by messaging protocols such as transport control protocol (TCP) which were designed before transaction oriented traffic became so widespread. Because transactional services often use protocols such as TCP this is a particular problem.
A fundamental characteristic of TCP is its ability to adapt the rate of flow of data across a network to provide near optimal use of the available network bandwidth. However, because transaction oriented traffic is short and bursty in nature, it does not allow the TCP adaptation process to operate effectively. Traffic bursts often result and cause congestion and the discarding of packets. This is discussed in more detail in the section headed “TCP” below.
Particular problems are involved for aggregate data flows when transaction oriented traffic is involved.
As described above, because transaction oriented traffic is short and bursty in nature, it does not allow the TCP adaptation process to operate effectively. Traffic bursts often result and cause congestion and the discarding of packets. This is particularly problematic for aggregate data flows, because packets are discarded not just from one flow within the aggregate, but are spread over many of the flows in the aggregate. Thus, the quality of service for many communication sessions are reduced, rather than that of just one communication session.
It is accordingly an object of the present invention to provide a method of admission control for data flows including those in the form of transaction oriented traffic, which overcomes or at least mitigates one or more of the problems noted above.